Especially in the case of a strategic realignment in companies or organizations, the choice increasingly falls on agile software development. Small, self-organized, and interdisciplinary teams should react to the demands of the market, the customer, or the organization in short intervals. Close to the business, added value is created every month (or even more often), prioritized according to business value. It won’t take long for Scrum to work its magic as a framework for these new demands.
All beginnings are difficult. Switching from learned procedures and ingrained processes to a completely new approach with new rules, roles, and regulatory deadlines involves risks. As with almost all changes, the full trust of all participants in the new playground won’t happen immediately with Scrum. Until understanding and trust in the new framework has reached the entire company or organization, including the Scrum teams, Scrum masters have to do a lot of coaching and persuading. A lack of trust and understanding of the importance of adhering to the rules often leads to Scrum not being implemented to its full extent, with all rules, roles, and events. The promising framework cannot realize its full potential.
This brings us back to the topic of: “Everyone wants to do it, but hardly anyone does it right”, whereby “right” serves as an illustration. The Scrum Guide is a valid guideline that defines roles, events, artifacts, and the associated rules in a framework, which must be adhered to in order to be able to fully develop the model. Challenges in the implementation of the framework’s specifications are quickly acknowledged and modified to make life easier for the team or make Scrum work better. In the following, we will present and examine the most common ScrumButs and their possible effects.
Scrum – but …
… not all events are necessary, and certainly not the Daily.
Class project management reporting in traffic lights or quality gates are run cyclically, maybe once a week, or less. Switching from this system to the frequency of events and meetings in the Scrum process is often questioned. The Daily, (a once-a-day 15-minute synchronization that looks at progress towards the sprint goal) is the most underestimated and misunderstood when moving to Scrum. Often the Daily is misinterpreted as a personal status report with the justification of individual productivity, and is all too often omitted. The Daily serves to improve communication, uncover obstacles on the way to the sprint goal, and synchronize with each other. The transparency gained in this process and the exchange of knowledge about current topics helps teams make decisions quickly. It provides a place and time to launch reviews towards adjustments. Skipping the Daily takes away the opportunity for the team to move from individual daily plans to the best planning for the day. If you commit to it, the 15 minutes is time well spent. It will quickly pay for itself. In our experience, many obstacles that were reported in a Daily were eliminated with far less effort than if they had only come to light four weeks later in a quality gate.
Scrum – but …
… a Scrum Master is not necessary: We have a project manager.
In many companies, tight hierarchies and entrenched project management structures still prevail. Especially with the changeover to Scrum and a misunderstanding of the individual roles, the Scrum Master is often replaced by project managers or team leaders under the guise of agility. At first, it doesn’t seem wrong. It also has the potential to be a good thing, and it should not imply that a project manager cannot develop into a good Scrum Master. Nevertheless, a change in thinking must also take place so that the goal of “agility” is always taken into consideration. As diverse as the role of a Scrum Master can be interpreted and lived out – there is one thing it is not: the role of a supervisor. Self-organizing teams thrive on truly organizing themselves independently of specifications. During a sprint, the Scrum Team reports only in the Daily Scrum and only to itself. There is no reporting chain to project managers or team leaders. Project managers often work along with their own target agreements. Especially in the early stages of a project and during the transition to an agile approach, these can run contrary to the goals that such a change entails. A team coming into contact with Scrum for the first time needs a certain start-up period, which may not be reflected in the project manager’s schedules. This is not to say that agile should fully dispense with project managers. They still serve a purpose as an interface into the company or the integration of agilely developed topics into company-wide structures. Nevertheless, the project manager should not replace the Scrum Master as a central role in the framework.
Scrum – but …
… we have to extend the sprint because we have not reached our sprint target.
Often, the sprint goal agreed upon at the beginning of the sprint cannot be fully achieved. Remembering our long-serving processes, it feels natural to continue working until the goal is achieved. The Scrum Guide defines the length of a sprint. There is no provision for extending a sprint. Once a Scrum team has settled in and gained the trust of the company, it is usually no big deal to conclude a sprint by adjusting the sprint goals in consultation with the Product Owner. The retrospective provides the space to make any issues that made the adjustment necessary transparent. If needed, it allows us to make adjustments so that the next spring goals can be achieved.
Scrum – but …
… we omit the Product Owner (PO) or the PO works in the development team.
Especially when forming Scrum teams for the first time, members of the development area can be deep in the subject matter and know the company so well that they want to omit the Product Owner. Sorting and maintaining backlog items, determining business value, and interacting with the business units can, of course, be done by someone on the development team. Now comes the “but” to this ScrumBut: Someone has to be accountable. That sounds more dramatic than it is. In practice, the Product Owner is also the place where everything comes together. Departments do not go directly to the development team for changes to backlogs. Only requirements that are agreed with the Product Owner are processed, and in the end, the Product Owner represents the team to the company. Combining this into one person and one role is preferable to spreading these tasks across a whole team. During a sprint, the development team needs the space and time to work undisturbed on the sprint goal. Any outside interference from departments is counterproductive to the team’s performance.
Scrum – but …
… this requirement absolutely has to be included in the current sprint.
Even with a well-established Scrum framework and short sprints of maximum of four weeks, again and again, departments approach the Product Owner during an ongoing sprint, requesting to add another item into the backlog at short notice. The guide clearly defines that the Scrum team issues a sprint target after forecasting the product backlog entries for the sprint. The team works on achieving this goal during the current sprint. In itself, this would contradict the inclusion of an additional item. But the Scrum Guide also states that the product owner, together with the team, can make a change to the sprint backlog scope in the current sprint if the scope of work deviates from original expectations. This gray area can be used with a view to the business value of the new backlog item and puts the added value for the customer first. However, use this procedure with caution. It should not become the rule.
Departments and product owners should approach the development team with a great deal of tact..
Conclusion
Dealing with the many “buts” that can come with implementing the Scrum framework is one of the biggest challenges of moving to agile and agile development. Most of the ScrumButs mentioned slow down team performance. They must be addressed directly and converted to the Scrum counterpart. Others are accepted because of their impact on teams and the added value for customers. In rare cases, there is a golden solution.
